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Abstract 

Though appropriate for core Internet infrastructure, the Inter- 
net Protocol is unsuited to routing within and between emerg- 
ing ad-hoc edge networks due to its dependence on hierarchi- 
cal, administratively assigned addresses. Existing ad-hoc rout- 
ing protocols address the management problem but do not scale 
to Internet-wide networks. The promise of ubiquitous network 
computing cannot be fulfilled until we develop an Unmanaged 
Internet Protocol (UIP), a scalable routing protocol that man- 
ages itself automatically. UIP must route within and between 
constantly changing edge networks potentially containing mil- 
lions or billions of nodes, and must still function within edge 
networks disconnected from the main Internet, all without im- 
posing the administrative burden of hierarchical address assign- 
ment. Such a protocol appears challenging but feasible. We 
propose an architecture based on self-certifying, cryptographic 
node identities and a routing algorithm adapted from distributed 
hash tables. 



1 Introduction 

The promise of ubiquitous computing is that people will 
soon routinely own many "smart" networked devices, 
some mobile, others perhaps built into their homes and 
offices, and all of which they can access and control from 
any location so long as appropriate security precautions 
are taken. Before we can expect ordinary, non-technical 
people to adopt this vision, however, the ad-hoc edge net- 
works in which these devices live must be able to manage 
themselves. Each device must be able to find and com- 
municate with its peers — whether connected directly, in- 
directly over a local-area network, or remotely across a 
long distance via the Internet — with no special configura- 
tion or other technical effort on the part of the user 




This research was conducted as pail of the IRIS project 
Jhttp: //pro ject-iris . net/ I, supported by the National Sci- 
ence Foundation under Cooperative Agreement No. ANI-0225660. 



Figure 1: Today's Internetworking Challenges 



The current Internet Protocol is unsuited to this pur- 
pose. IPv4 and IPv6, with their accompanying routing, 
naming, and management protocols, have evolved around 
the requirements of core network infrastructure: corpo- 
rate, academic, and government networks deployed and 
managed by skilled network administrators. IP's hierar- 
chical address architecture in particular is fundamentally 
dependent on skilled network management. Current ad- 
hoc networking protocols by themselves are not sufficient 
either, because they are only scalable to local-area net- 
work sizes of a few hundreds or thousands of nodes. 

To achieve ubiquitous network computing, we need an 
Unmanaged Internet Protocol, or UIP, that combines the 
self-management of ad-hoc networks with the scalability 
of IP. As illustrated in Figure ^ achieving this goal in to- 
day's chaotic mix of networking technologies also means 
routing traffic automatically and securely through NATs, 
and transparently bridging IPv4, IPv6, and other address 
domains. We propose an architecture based on scal- 
able identity-based routing, or routing based on topology- 
independent node identifiers. While more difficult than 
routing over topology-dependent addresses such as IP 
addresses, there is evidence that scalable identity-based 
routing is possible and practical. 

This position paper is organized as follows. Section |2] 
lays out the motivation for UIP and the inadequacies of 
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current solutions. Section |3l proposes and outlines an 
identity-based UIP routing architecture, and Section0]de- 
scribes implementation status and deployment. Section|5] 
summarizes related work, and Section|6]concludes. 

2 Motivation for UIP 

The original ARPAnet vision was to enable computer 
users to communicate and share resources with users of 
any other connected computer [16 27 1. This vision has 
evolved into the modern Internet Protocol, whose purpose 
is to implement any-to-any connectivity between hosts, 
whether connected directly or indirectly via paths cross- 
ing many administrative domains. While physical and 
link-layer technologies such as Ethernet provide low-level 
building blocks for communication, and higher-level pro- 
tocols enable applications and users to take advantage of 
the network, interoperable end-to-end connectivity via IP 
remains the Internet's central focus. 

Technical, social, and economic pressures have hin- 
dered the achievement of this vision, however The proto- 
cols underlying the Internet were designed by technically 
savvy individuals who understand how networks work but 
often do not understand how non-technical users work. 
As a result many aspects of network operation still require 
careful and skilled management. We desire and increas- 
ingly expect that everyone should be able to use the Inter- 
net and deploy networked devices, and strong economic 
incentives exist for businesses to sell Internet-enabled 
hardware and Internet-based services to technically un- 
sophisticated users. Since businesses seek lowest-cost 
paths to profitable solutions, the commercial Internet has 
evolved — via a chaotic series of hacks and extensions — 
into a system geared toward particular usage patterns that 
facilitate business opportunities, often at the expense of 
interoperability and general end-to-end connectivity. 

2.1 The Edge Network Management Crisis 

An unsophisticated user can now buy a computer, connect 
it to the Internet, and use it for browsing the Web, reading 
E-mail, and shopping on-line. Users who are a bit more 
adventurous but still relatively non-technical may set up a 
small home network and surf the Web from several com- 
puters at once. But consider the following scenario: 

1. Joe User is working at home on his laptop. He 
has remote shell and database access sessions open, 
through his WiFi home network, to his desktop PC 
and to a machine at his workplace. 



2. Joe's friend Jim calls and invites him over Joe puts 
his laptop into sleep mode and hops into his car 

3. Joe stops for a bite to eat on the way to Jim's, and 
scribbles some notes on his PDA in the restaurant. 

4. Upon returning to his car, Joe tries to synchronize his 
PDA with his laptop, but discovers they won't talk 
to each other even though they're both WiFi-enabled 
and are at most a foot apart. Being unfamiliar with 
the technical details of IP networks, he doesn't real- 
ize that this is because (a) the WiFi adapters are in 
infrastructure rather than ad-hoc mode, and (b) even 
if they could communicate at the link layer, neither 
machine would be able to get an IP address because 
there's no DHCP 1 6 1 server nearby. 

5. Joe arrives at Jim's place, and the two brainstorm 
about their project at work. Joe takes out his lap- 
top and wakes it up. Since Jim also has an Internet- 
connected WiFi home network, Joe hopes to use 
Jim's Internet access and resume his existing appli- 
cation sessions to his desktop PCs at home and work. 
Again Joe is disappointed. After figuring out that he 
has to remove and re-insert his laptop's WiFi card in 
order to get it to recognize Jim's network at aU, Joe's 
application sessions are gone. He does not realize 
that moving to a new attachment point changed his 
IP address, breaking his existing TCP connections. 

6. Joe tries to re-start his application sessions, but finds 
that he cannot even locate let alone connect with his 
desktop PC at home. He doesn't realize that this is 
because (a) his ISP did not give him a permanent IP 
address useable for connecting remotely to his home 
network, and (b) even with a permanent IP address, 
his desktop PC would still be inaccessible because it 
is behind a network address translator I3II . 

Joe's naive expectations of his networked devices are 
not fundamentally unreasonable, and all of the problems 
above are solvable with current technology. Joe could in 
theory: (a) configure his home NAT to assign fixed site- 
local IP addresses to his desktop and laptop PCs at home; 
(b) configure his NAT to open the appropriate external 
ports for remote access and forward incoming connec- 
tions on those ports to his desktop PC; (c) register for a 
global DNS host name with a Dynamic DNS 1 35 1 service 
provider; (d) set up his desktop PC to update this DNS 
name periodically with the dynamic IP address his ISP 
assigns to his home NAT; (e) set up Mobile IP 1 24 J so that 
his desktop PC at home will intercept packets destined for 
his laptop's "home" IP address, and tunnel them to his 
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laptop at its actual connection point while connected else- 
where; (f) run daemons on his laptop and PDA that detect 
when no infrastructure-mode WiFi access point or DHCP 
service is available, and automatically switch into ad-hoc 
mode using a routing protocol such as AODV |23 1. 

Only the most dedicated, desperate, or geeky will go to 
this trouble, however. To most users, having a "working" 
network means being able to get to Google, CNN, and 
Amazon.com. Any "ubiquitous" connectivity outside this 
commercial client/server straitjacket is fickle, unreliable, 
and management-intensive if available at all. 
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Figure 2: UIP in the Internet Protocol Architecture 



2.2 IP Networks Require Management 

The scalability and efficiency of the current Inter- 
net Protocol relies on Classless Inter-Domain Routing 
(CIDR) 1 25 1, in which network nodes are assigned ad- 
dresses whose hierarchical structure reflects the routing 
topology. BGP routers take advantage of the hierarchical 
structure of IP addresses, aggregating information about 
distant nodes and networks sharing a common address 
prefix into a single routing table entry 1 26 1 . 

While this hierarchical address assignment scheme 
makes the core Internet infrastructure efficient and scal- 
able, it is precisely this address assignment scheme that 
makes edge networks brittle and difficult to manage. 
Whenever a node moves or its surrounding network is 
renumbered, the node's IP address must change. Stat- 
ically configuring and maintaining the IP addresses of 
many nodes is challenging even for technically compe- 
tent network administrators, leading to organizational re- 
sistance against IP address renumbering |5|. Dynamic 
address assignment transfers administrative responsibil- 
ity from edge nodes to DHCP servers, at the expense of 
making edge nodes unable to communicate at all with- 
out access to a DHCP server. Workarounds in which 
nodes choose their own local IP addresses after failing 
to contact a DHCP server |19| are slow, unreliable, and 
at best allow nodes to communicate only with immediate 
link-neighbors while disconnected from the main Internet. 
These issues will persist even into a future IPv6 world in 
which there are "enough" IP addresses for everyone and 
network address translators do not exist, because the basic 
address architecture remains the same in IPv6. 

2.3 Ad-Hoc Networks Do Not Scale 

Classic distance-vector [13' "9l and link-state [21] rout- 
ing protocols, as well as ad-hoc routing variants such as 
DSR 1121 and AODV 1231 . require every node to store and 
regularly exchange information about every other node in 



the network. This linear per-node storage and/or band- 
width overhead limits the scalability of these protocols to 
a few hundreds or thousands of nodes. While ad-hoc pro- 
tocols can be used to route within a particular IP subnet, 
this subnet must be centrally allocated and managed in or- 
der to be globally routable on the Internet, and all partici- 
pating nodes must be assigned to that subnet. Configuring 
each node statically is tedious and inconvenient, while us- 
ing DHCP again makes the nodes unable to communicate 
with each other while out of range of a DHCP server 

To fulfill the promise of ubiquitous networking, an edge 
network routing protocol must be self-managing not only 
on a local scale, but also on a global scale. We need an 
ad-hoc routing protocol that can seamlessly route pack- 
ets throughout an Internet-wide federation of ad-hoc edge 
networks, consisting of potentially millions or billions of 
edge nodes that frequently hop from one edge network 
to another This protocol must still provide reliable ad- 
hoc routing within edge networks that are temporarily or 
permanently disconnected from the Internet. This is the 
purpose of Unmanaged Internet Protocol, or UIP. 

3 Proposed UIP Architecture 

Since IP does an excellent job of routing packets effi- 
ciently through the managed core Internet infrastructure, 
we intend UIP not to replace IP but to run on top of it, as 
a new network layer component (Figure |2j. In our pro- 
posed architecture, UIP appears to upper-level transport 
and application protocols as a new address/protocol fam- 
ily, much hke IPv6 does now. 

3.1 Node Identities 

To refer to other UIP nodes, applications use self- 
certifying cryptographic identifiers that are stable over 
time and independent of network topology. All con- 
nections between UIP nodes are privacy- and integrity- 
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protected by default, as in IPSEC rT4l. A node's UIP 
identifier is a hash of the node's public key, making iden- 
tifiers self-certifying, like Moskowitz's host identities f^UI 
or SFS pathnames 1181 . Cryptographic identities provide 
several properties crucial to achieving robust connectivity 
in future ubiquitous networking environments: 

• Any node can create a globally unique UIP identi- 
fier at any time without reference to central authori- 
ties. The identifier's uniqueness depends only on the 
strength of the cryptographic hash used to create it. 

• A node's identifier remains valid as long as desired. 
Security practice may limit the lifetimes of long-term 
keys and node identities to a few years, but since this 
is the useful lifetime of most PCs, many nodes may 
never have to change identifiers. 

• Since a node identifier contains no topology informa- 
tion, the node can retain its identity when it moves or 
the surrounding network topology changes. 

• A node can cryptographically prove ownership of an 
identifier using the associated private key, preventing 
an attacker from stealing its identity. 

• A node can have multiple identities simultaneously, 
representing distinct services or "virtual hosts" on 
one physical machine for example. 

• The network layer does not depend on centralized 
public key infrastructure (PKI). Higher layers may 
use PKI to map convenient names to node identifiers, 
but given a node identifier, finding and connecting 
securely to that node is fully decentralized. 

3.2 UIP Routing 

UIP's primary technical challenge is to forward traffic 
from any node to any other in an Internet-scale network, 
without the help of hierarchically structured node ad- 
dresses. Since UIP node identifiers are unrelated to net- 
work topology, they have no locality properties routers 
can use to aggregate routing information about distant 
nodes. Requiring every node to store and propagate rout- 
ing information about every other node in an Internet- 
scale network may arguably be viable for a desktop PC 
with a high-speed Internet connection, but is definitely 
impractical for small, low-power devices such as PDAs. 

3.2.1 Approaches to Identity-Based Routing 

Bellman-Ford and similar routing algorithms find optimal 
routes, based on either hop count or some per-link cost 
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Figure 3: Forwarding via Virtual Links 

metric. We do not need optimal routing, however: in 
practice it suffices to find reasonably efficient mutts,. The 
routes that BGP finds are probably less than optimal al- 
ready, due to the difficulty of supporting site multihoming 
in the Internet's hierarchical address model 1 1 1, and the 
lack of incentive for ISPs to reveal all of their peering re- 
lationships in their BGP advertisements. 

Route efficiency is usually measured in terms of stretch: 
the length of the route discovered by the protocol over the 
length of the best possible route. Algorithms now exist 
that can route through an iV-node network with arbitrary 
node labels, using 0{^fN) bits of routing table state per 
node, and a small constant maximum stretch |4|. 

In practice, we do not even necessarily demand that 
all nodes have sublinear storage requirements. We might 
accept a routing protocol that has sublinear overhead on 
most nodes, but requires a few nodes present in the net- 
work to have Vl{N) storage and/or bandwidth. It is critical 
to our ubiquitous networking goals, however, that these 
"supernodes" do not need to be hard-wired as such. Any 
node must be able to take on that role dynamically when- 
ever supernodes are needed and the surrounding network 
is small enough. While Joe's laptop and PDA are con- 
nected to the Internet, for example, their ability to route 
to distant edge nodes might depend on a massive central 
server somewhere that continuously maintains a complete 
map of the Internet. If Joe takes several network devices 
with him into the mountains where there is no Internet ac- 
cess, however, each device must be able to take on super- 
node responsibilities as necessary to direct traffic within 
any smaller ad-hoc network he may form. Joe's laptop and 
other small devices never need to map the entire Internet, 
but only the smaller edge networks Joe may participate in 
while disconnected from the Internet. 

3.2.2 Converting DHTs into Routing Algorithms 

We are experimenting with a scalable routing protocol 
for UIP derived from the Kademlia distributed hash table 
(DHT) itm . This protocol, detailed elsewhere Q, empir- 
ically achieves 0{log N) storage and maintenance over- 



4 



head per node and an average stretch of 2 on simulated 
networks. We have not yet formalized the algorithm or 
derived theoretical performance properties, however. 

DHTs normally implement only indexing and lookup, 
relying on underlying protocols to provide connectivity 
between all participants. Our protocol extends Kademlia 
to function over any topology through the use of recur- 
sive source routes, or virtual links. Once any two nodes 
have connected and established a "neighbor" relationship, 
ether node can use that relationship to build further neigh- 
bor relationships recursively, covering longer topological 
distances. In Figure |3j for example, node A uses physi- 
cal links AB and BC to build a virtual link AC, thereby 
establishing a neighbor relationship with C. Node A then 
uses virtual link AC to build a recursive virtual link to C's 
physical neighbor D. Node D can now communicate with 
node A via its physical link to C and C's virtual link to 
A, without having to know the details of the path between 
C and A. Node D might not know about the existence of 
node B at all. In this way the routing protocol abstracts 
the details of routing at different levels, achieving an ef- 
fect analogous to IP address aggregation without actually 
depending on hierarchically assigned addresses. 

A node n sorts its neighbors rii into buckets, according 
to the longest common prefix length in bits between n's 
and rii's identifier. To join the network, n needs a physi- 
cal link to some existing node rii. Node n searches ni's 
neighbor table for another node 712 with a longer common 
prefix, and builds a virtual link through rii to n2- This 
process continues until n finds the node with the closest 
identifier to its own. If a suitable connectivity invariant is 
maintained, every node in the resulting structure can find 
and build a forwarding path to any other node on demand. 

4 Implementation and Deployment 

A UIP prototype is under development, which we look 
forward to using and evaluating shortly. For portability, 
the prototype runs as an application-level daemon, com- 
municating with other nodes primarily over UDP. The 
daemon can also directly utilize the link layers of some 
systems if it has appropriate privileges. Multiple local 
applications can share a single UIP daemon, interacting 
through a proxy library that exports a standard sockets- 
based interface. To simplify initial deployment of UIP, ap- 
plications without special privileges can be bundled with 
their own UIP daemon, which the application starts auto- 
matically if a systemwide daemon is not available. 

An immediate benefit of UIP is that it allows applica- 
tions to establish secure, peer-to-peer connections through 
NAT and firewall barriers without special effort, as long as 



there are some widely-accessible UIP nodes on the Inter- 
net through which the daemon can forward traffic if nec- 
essary. The UIP daemon implements UDP hole punch- 
ing [?] as an application-transparent optimization, utiliz- 
ing widely-accessible UIP nodes as "introducers" to es- 
tablish direct IP-based peer-to-peer communication paths 
across many NATs and firewalls. The daemon falls back 
to explicit forwarding whenever hole punching fails, en- 
suring maximum robustness. 



5 Related Work 

UIP is a fusion of ideas from many projects. Like Re- 
silient Overlay Networks (3), UIP introduces a routing 
layer above IP that can route around discontinuities and 
failures in the Internet, but UIP seeks to be scalable and 
self-managing as well as resilient. Ad-hoc routing proto- 
cols such as DSR 1 12| address the management problem 
at the local level but are not scalable to Internet-wide ad- 
hoc networks. Landmark 1331 and AODV 1231 offer scal- 
ability under localized traffic patterns, but not under the 
global traffic patterns of the Internet. 

UIP node identities are similar to those of Moskowitz's 
proposed Host Identity Protocol |20|, but UIP uses iden- 
tities for routing as well as authentication. The Inter- 
net Indirection Infrastructure 1 32 1 provides location- 
independent host identities, multicast and anycast com- 
munication, and NAT traversal, but does not implement a 
general-purpose routing protocol that can function inde- 
pendently from the Internet. 

Many Internet host mobility solutions have been pro- 
posed. Higher-level naming systems can provide appli- 
cations independence from their host's IP address 1351 12| 
'291, at the cost of tying applications to a particular naming 
scheme and making it difficult to maintain connections 
as the host moves |30|. Mobile IP 1241 allows a mobile 
host to roam without breaking outstanding TCP connec- 
tions or UDP bindings, but requires each mobile host to 
have a stable "home" IP address through which packets 
are tunneled. A similar illusion of a static IP address can 
be achieved with IP multicast | 22, 10 1. 

Work on peer-to-peer connectivity through firewalls 
and NATs fl 11 has led to various special-purpose proto- 
cols LI 5. ■28.. 34.1 . UDP hole punching [?] allows peer-to- 
peer connectivity through many NATs, but not all, with- 
out the use of explicit proxy protocols. Name-based rout- 
ing |8| offers more general bridging of IP address do- 
mains, but its ties to the management-heavy domain name 
system make it unsuitable for ad-hoc networks. 
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6 Conclusion 

Ubiquitous network computing will require an ad-hoc 
routing protocol that can not only route autonomously 
within small edge networks of hundreds or thousands of 
nodes, but can seamlessly route among a large Internet- 
connected federation of edge networks. The traditional 
solution to scalability, hierarchical address assignment, is 
unsuited to edge networks due to its management costs. 
Scalable identity-based routing protocols appear feasi- 
ble and represent a promising research direction, though 
many practical technical problems remain unsolved. Be- 
sides providing a key building block for ubiquitous net- 
work computing, scalable identity-based routing may also 
help address the more immediate problems of Internet 
host mobility, NAT traversal, and bridging between IPv4, 
IPv6, and other address domains. 
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